SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Event loop</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Event loop</span></span>

</h1>

</header>

<p>In <a href="Computer_science" title="Computer science">computer science</a>, the <b>event loop</b> (also known as <b>message dispatcher</b>, <b>message loop</b>, <b>message pump</b>, or <b>run loop</b>) is a programming construct or <a href="Software_design_pattern" title="Software design pattern">design pattern</a> that waits for and dispatches <a href="Event-driven_programming" title="Event-driven programming">events</a> or <a href="Message_Passing_Interface" title="Message Passing Interface">messages</a> in a <a href="Computer_program" title="Computer program">program</a>. The event loop works by making a request to some internal or external "event provider" (that generally <a href="Blocking_(computing)" title="Blocking (computing)">blocks</a> the request until an event has arrived), then calls the relevant <a href="Event_handler" class="mw-redirect" title="Event handler">event handler</a> ("dispatches the event").

</p><p>It is also commonly implemented in servers such as <a href="Web_server" title="Web server">web servers</a>.

</p><p>The event loop may be used in conjunction with a <a href="Reactor_pattern" title="Reactor pattern">reactor</a>, if the event provider follows the <a href="#File_interface">file interface</a>, which can be selected or 'polled' (the Unix system call, not actual <a href="Polling_(computer_science)" title="Polling (computer science)">polling</a>). The event loop almost always operates asynchronously with the message originator.

</p><p>When the event loop forms the central <a href="Control_flow" title="Control flow">control flow</a> construct of a program, as it often does, it may be termed the <b>main loop</b> or <b>main event loop</b>. This title is appropriate, because such an event loop is at the highest level of control within the program.

</p>

<div class="mw-heading mw-heading2"><h2 id="Message_passing">Message passing</h2></div>

<p>Message pumps are said to 'pump' messages from the program's <a href="Message_queue" title="Message queue">message queue</a> (assigned and usually owned by the underlying operating system) into the program for processing. In the strictest sense, an event loop is one of the methods for implementing <a href="Inter-process_communication" title="Inter-process communication">inter-process communication</a>. In fact, message processing exists in many systems, including a <a href="Kernel_(operating_system)" title="Kernel (operating system)">kernel-level</a> component of the <a href="Mach_(kernel)" title="Mach (kernel)">Mach operating system</a>. The event loop is a specific implementation technique of systems that use <a href="Message_passing" title="Message passing">message passing</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Alternative_designs">Alternative designs</h2></div>

<p>This approach is in contrast to a number of other alternatives:

</p>

<ul><li>Traditionally, a program simply ran once, then terminated. This type of program was very common in the early days of computing, and lacked any form of user interactivity. This is still used frequently, particularly in the form of <a href="Command-line_interface" title="Command-line interface">command-line-driven</a> programs. Any <a href="Parameter_(computer_programming)" title="Parameter (computer programming)">parameters</a> are set up in advance and passed in one go when the program starts.</li>

<li>Menu-driven designs. These still may feature a main loop, but are not usually thought of as <a href="Event-driven_programming" title="Event-driven programming">event driven</a> in the usual sense. Instead, the user is presented with an ever-narrowing set of options until the task they wish to carry out is the only option available. Limited interactivity through the menus is available.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Usage">Usage</h2></div>

<p>Due to the predominance of <a href="Graphical_user_interface" title="Graphical user interface">graphical user interfaces</a>, most modern applications feature a main loop. The <code>get_next_message()</code> routine is typically provided by the operating system, and <a href="Blocking_(computing)" title="Blocking (computing)">blocks</a> until a message is available. Thus, the loop is only entered when there is something to process.

</p>

<pre><b>function</b> main

initialize()

<b>while</b> message != quit

message := get_next_message()

process_message(message)

<b>end</b> <b>while</b>

<b>end</b> <b>function</b>

</pre>

<div class="mw-heading mw-heading2"><h2 id="File_interface">File interface</h2></div>

<p>Under <a href="Unix" title="Unix">Unix</a>, the "<a href="Everything_is_a_file" title="Everything is a file">everything is a file</a>" paradigm naturally leads to a file-based event loop. Reading from and writing to files, inter-process communication, network communication, and device control are all achieved using file I/O, with the target identified by a <a href="File_descriptor" title="File descriptor">file descriptor</a>. The <a href="Select_(Unix)" title="Select (Unix)">select</a> and <a href="Poll_(Unix)" title="Poll (Unix)">poll</a> system calls allow a set of file descriptors to be monitored for a change of state, e.g. when data becomes available to be read.

</p><p>For example, consider a program that reads from a continuously updated file and displays its contents in the <a href="X_Window_System" title="X Window System">X Window System</a>, which communicates with clients over a socket (either <a href="Unix_domain_socket" title="Unix domain socket">Unix domain</a> or <a href="Berkeley_sockets" title="Berkeley sockets">Berkeley</a>):

</p>

<span class="n">file_fd</span> <span class="o">=</span> <span class="nb">open</span><span class="p">(</span><span class="s2">"logfile.log"</span><span class="p">)</span>

<span class="n">x_fd</span> <span class="o">=</span> <span class="n">open_display</span><span class="p">()</span>

<span class="n">construct_interface</span><span class="p">()</span>

<span class="k">while</span> <span class="kc">True</span><span class="p">:</span>

<span class="n">rlist</span><span class="p">,</span> <span class="n">_</span><span class="p">,</span> <span class="n">_</span> <span class="o">=</span> <span class="n">select</span><span class="o">.</span><span class="n">select</span><span class="p">([</span><span class="n">file_fd</span><span class="p">,</span> <span class="n">x_fd</span><span class="p">],</span> <span class="p">[],</span> <span class="p">[]):</span>

<span class="k">if</span> <span class="n">file_fd</span> <span class="ow">in</span> <span class="n">rlist</span><span class="p">:</span>

<span class="n">append_to_display</span><span class="p">(</span><span class="n">data</span><span class="p">)</span>

<span class="n">send_repaint_message</span><span class="p">()</span>

<span class="k">if</span> <span class="n">x_fd</span> <span class="ow">in</span> <span class="n">rlist</span><span class="p">:</span>

<span class="n">process_x_messages</span><span class="p">()</span>

</pre></div>

<div class="mw-heading mw-heading3"><h3 id="Handling_signals">Handling signals</h3></div>

<p>One of the few things in Unix that does not conform to the file interface are asynchronous events (<a href="Signal_(IPC)" title="Signal (IPC)">signals</a>). Signals are received in <a href="Signal_(IPC)#Handling_signals" title="Signal (IPC)">signal handlers</a>, small, limited pieces of code that run while the rest of the task is suspended; if a signal is received and handled while the task is blocking in <code>select()</code>, select will return early with <a href="Errno.h" title="Errno.h">EINTR</a>; if a signal is received while the task is <a href="CPU_bound" class="mw-redirect" title="CPU bound">CPU bound</a>, the task will be suspended between instructions until the signal handler returns.

</p><p>Thus an obvious way to handle signals is for signal handlers to set a global flag and have the event loop check for the flag immediately before and after the <code>select()</code> call; if it is set, handle the signal in the same manner as with events on file descriptors. Unfortunately, this gives rise to a <a href="Race_condition" title="Race condition">race condition</a>: if a signal arrives immediately between checking the flag and calling <code>select()</code>, it will not be handled until <code>select()</code> returns for some other reason (for example, being interrupted by a frustrated user).

</p><p>The solution arrived at by <a href="POSIX" title="POSIX">POSIX</a> is the <code>pselect()</code> call, which is similar to <code>select()</code> but takes an additional <code>sigmask</code> parameter, which describes a <i>signal mask</i>. This allows an application to mask signals in the main task, then remove the mask for the duration of the <code>select()</code> call such that signal handlers are only called while the application is <a href="I/O_bound" title="I/O bound">I/O bound</a>. However, implementations of <code>pselect()</code> have not always been reliable; versions of Linux prior to 2.6.16 do not have a <code>pselect()</code> system call,<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> forcing <a href="Glibc" title="Glibc">glibc</a> to emulate it via a method prone to the very same race condition <code>pselect()</code> is intended to avoid.

</p><p>An alternative, more portable solution, is to convert asynchronous events to file-based events using the <i>self-pipe trick</i>,<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> where "a signal handler writes a byte to a pipe whose other end is monitored by <code>select()</code> in the main program".<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> In <a href="Linux_kernel" title="Linux kernel">Linux kernel</a> version 2.6.22, a new system call <code>signalfd()</code> was added, which allows receiving signals via a special file descriptor.

</p>

<div class="mw-heading mw-heading2"><h2 id="Implementations">Implementations</h2></div>

<div class="mw-heading mw-heading3"><h3 id="HTML/JavaScript">HTML/JavaScript</h3></div>

<p>A web page and its JavaScript typically run in a single-<a href="Thread_(computing)" title="Thread (computing)">threaded</a> <a href="Web_browser" title="Web browser">web browser</a> process. The browser process deals with <a href="Message_(computer_science)" class="mw-redirect" title="Message (computer science)">messages</a> from a <a href="Queue_(abstract_data_type)" title="Queue (abstract data type)">queue</a> one at a time. A JavaScript <a href="Subroutine" class="mw-redirect" title="Subroutine">function</a> or another browser event might be associated with a given message. When the browser process has finished with a message, it proceeds to the next message in the queue.

</p>

<div class="mw-heading mw-heading3"><h3 id="Windows_applications">Windows applications</h3></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Message_loop_in_Microsoft_Windows" title="Message loop in Microsoft Windows">Message loop in Microsoft Windows</a></div>

<p>On the <a href="Microsoft_Windows" title="Microsoft Windows">Microsoft Windows</a> operating system, a process that interacts with the user <i>must</i> accept and react to incoming messages, which is almost inevitably done by a <a href="Message_loop_in_Microsoft_Windows" title="Message loop in Microsoft Windows">message loop</a> in that process. In Windows, a message is equated to an event created and imposed upon the operating system. An event can be user interaction, network traffic, system processing, timer activity, inter-process communication, among others. For non-interactive, I/O only events, Windows has <a href="Input/output_completion_port" title="Input/output completion port">I/O completion ports</a>. I/O completion port loops run separately from the Message loop, and do not interact with the Message loop out of the box.

</p><p>The "heart" of most <a href="Win32" class="mw-redirect" title="Win32">Win32</a> <a href="Application_software" title="Application software">applications</a> is the <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms633559.aspx">WinMain()</a> function, which calls <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms644936.aspx">GetMessage()</a> in a loop. GetMessage() blocks until a message, or "event", is received (with function <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms644943.aspx">PeekMessage()</a> as a non-blocking alternative). After some optional processing, it will call <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms644934.aspx">DispatchMessage()</a>, which dispatches the message to the relevant handler, also known as <a href="WindowProc" title="WindowProc">WindowProc</a>. Normally, messages that have no special <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms633573.aspx">WindowProc()</a> are dispatched to <a href="WindowProc#Default_processing" title="WindowProc">DefWindowProc</a>, the default one. DispatchMessage() calls the WindowProc of the <a href="Handle_(computing)" title="Handle (computing)">HWND</a> <a href="Smart_pointer" title="Smart pointer">handle</a> of the message (registered with the <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms633586.aspx">RegisterClass()</a> function).

</p>

<div class="mw-heading mw-heading4"><h4 id="Message_ordering">Message ordering</h4></div>

<p>More recent versions of Microsoft Windows guarantee to the programmer that messages will be delivered to an application's message loop in the order that they were perceived by the system and its peripherals. This guarantee is essential when considering the design consequences of <a href="Thread_(computing)" title="Thread (computing)">multithreaded</a> applications.

</p><p>However, some messages have different rules, such as messages that are always received last, or messages with a different documented priority.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="X_Window_System">X Window System</h3></div>

<div class="mw-heading mw-heading4"><h4 id="Xlib_event_loop">Xlib event loop</h4></div>

<p><a href="X_Window_System" title="X Window System">X</a> applications using <a href="Xlib" title="Xlib">Xlib</a> directly are built around the <code>XNextEvent</code> family of functions; <code>XNextEvent</code> blocks until an event appears on the event queue, whereupon the application processes it appropriately. The Xlib event loop only handles window system events; applications that need to be able to wait on other files and devices could construct their own event loop from primitives such as <code>ConnectionNumber</code>, but in practice tend to use <a href="Thread_(computing)" title="Thread (computing)">multithreading</a>.

</p><p>Very few programs use Xlib directly. In the more common case, GUI toolkits based on Xlib usually support adding events. For example, toolkits based on <a href="X_Toolkit_Intrinsics" title="X Toolkit Intrinsics">Xt Intrinsics</a> have <code>XtAppAddInput()</code> and <code>XtAppAddTimeout()</code>.

</p><p>It is not safe to call Xlib functions from a signal handler, because the X application may have been interrupted in an arbitrary state, e.g. within <code>XNextEvent</code>. See <a rel="nofollow" class="external autonumber" href="http://www.ist.co.uk/motif/books/vol6A/ch-26.fm.html">[1]</a> for a solution for X11R5, X11R6 and Xt.

</p>

<div class="mw-heading mw-heading3"><h3 id="GLib_event_loop">GLib event loop</h3></div>

<p>The <a href="GLib" title="GLib">GLib</a> event loop was originally created for use in <a href="GTK" title="GTK">GTK</a> but is now used in non-GUI applications as well, such as <a href="D-Bus" title="D-Bus">D-Bus</a>. The resource polled is the collection of <a href="File_descriptor" title="File descriptor">file descriptors</a> the application is interested in; the polling block will be interrupted if a <a href="Signal_(IPC)" title="Signal (IPC)">signal</a> arrives or a <a href="Timeout_(computing)" title="Timeout (computing)">timeout</a> expires (e.g. if the application has specified a timeout or idle task). While GLib has built-in support for file descriptor and child termination events, it is possible to add an event source for any event that can be handled in a prepare-check-dispatch model.<a rel="nofollow" class="external autonumber" href="http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#mainloop-states">[2]</a>

</p><p>Application libraries that are built on the GLib event loop include <a href="GStreamer" title="GStreamer">GStreamer</a> and the <a href="Asynchronous_I/O" title="Asynchronous I/O">asynchronous I/O</a> methods of <a href="GnomeVFS" title="GnomeVFS">GnomeVFS</a>, but <a href="GTK" title="GTK">GTK</a> remains the most visible client library. Events from the <a href="Windowing_system" title="Windowing system">windowing system</a> (in <a href="X_Window_System" title="X Window System">X</a>, read off the X <a href="Unix_domain_socket" title="Unix domain socket">socket</a>) are translated by <a href="GDK" title="GDK">GDK</a> into GTK events and emitted as GLib signals on the application's widget objects.

</p>

<div class="mw-heading mw-heading3"><h3 id="macOS_Core_Foundation_run_loops">macOS Core Foundation run loops</h3></div>

<p>Exactly one CFRunLoop is allowed per thread, and arbitrarily many sources and observers can be attached. Sources then communicate with observers through the run loop, with it organising queueing and dispatch of messages.

</p><p>The CFRunLoop is abstracted in <a href="Cocoa_(API)" title="Cocoa (API)">Cocoa</a> as an NSRunLoop, which allows any message (equivalent to a function call in non-<a href="Reflective_programming" title="Reflective programming">reflective</a> runtimes) to be queued for dispatch to any object.

</p>

<ul><li><a href="Asynchronous_I/O" title="Asynchronous I/O">Asynchronous I/O</a></li>

<li><a href="Event-driven_programming" title="Event-driven programming">Event-driven programming</a></li>

<li><a href="Inter-process_communication" title="Inter-process communication">Inter-process communication</a></li>

<li><a href="Message_passing" title="Message passing">Message passing</a></li>

<li>The <i>game loop</i> in <a href="Game_programming" class="mw-redirect" title="Game programming">Game programming</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://kernelnewbies.org/Linux_2_6_16">"Linux_2_6_16 - Linux Kernel Newbies"</a>. <i>kernelnewbies.org</i><span class="reference-accessdate">. Retrieved <span class="nowrap">2021-03-03</span></span>.</cite></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text"><cite id="CITEREFD._J._Bernstein" class="citation web cs1">D. J. Bernstein. <a rel="nofollow" class="external text" href="http://cr.yp.to/docs/selfpipe.html">"The self-pipe trick"</a>.</cite></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text">BUGS, <span class="neverexpand"><code><a rel="nofollow" class="external text" href="https://manned.org/pselect.2">pselect(2)</a></code></span>: synchronous I/O multiplexing – <a href="Linux" title="Linux">Linux</a> Programmer's <a href="Man_page" title="Man page">Manual</a> – System Calls</span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-4">^</a></b></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms644936.aspx">GetMessage() function</a> with message priority list.</span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.microsoft.com/msj/0795/dilascia/dilascia.aspx">Meandering Through the Maze of MFC Message and Command Routing</a></li>

<li><a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms644928.aspx">Using Messages and Message Queues (MSDN)</a></li>

<li><a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms633570.aspx">Using Window Procedures (MSDN)</a></li>

<li><a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/ms633573.aspx">WindowProc (MSDN)</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-06-16" href="https://en.wikipedia.org/wiki/?title=Event_loop&oldid=1295917877">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>